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Abstract 

A  hierarchical  module  system  is  an  effective  tool  for  structuring  large  programs.  Strictly  hierarchical  module 
systems  impose  an  acyclic  ordering  on  import  dependencies  among  program  units.  This  can  impede  modular 
programming  by  forcing  mutually-dependent  components  to  be  consolidated  into  a  single  module.  Recently 
there  have  been  several  proposals  for  module  systems  that  admit  cyclic  dependencies,  but  it  is  not  clear  how 
these  proposals  relate  to  one  another,  nor  how  one  might  integrate  them  into  an  expressive  module  system 
such  as  that  of  Standard  ML  or  O’Caml.  To  address  this  question  we  provide  a  type-theoretic  analysis  of 
the  notion  of  a  recursive  module  in  the  context  of  the  “phase-distinction”  formalism  for  higher-order  module 
systems.  We  extend  this  calculus  with  a  recursive  module  mechanism  and  a  new  form  of  signature,  called  a 
recursively-dependent  signature^  to  support  the  definition  of  recursive  modules.  These  extensions  are  justified 
by  an  interpretation  in  terms  of  more  primitive  language  constructs.  This  interpretation  may  also  serve  as 
a  guide  for  implementation. 
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1  Introduction 


Hierarchical  decomposition  is  a  fundamental  design  principle  for  controlling  the  complexity  of  large  pro¬ 
grams.  According  to  this  principle  a  software  system  is  to  be  decomposed  into  a  collection  of  modules  whose 
dependency  relationships  form  a  directed,  acyclic  graph.  Most  modern  programming  languages  include  mod¬ 
ule  systems  that  support  hierarchical  decomposition.  Many,  such  as  Standard  ML  [13]  and  O’Caml  [12],  also 
support  parameterized,  or  generic,  modules  to  better  support  code  re-use. 

There  is  no  question  that  hierarchical  design  is  an  important  tool  for  structuring  large  systems.  It  has 
often  been  noted,  however,  that  strict  adherence  to  a  hierarchical  architecture  can  preclude  the  decomposition 
of  a  system  into  “mind-sized”  components.  In  some  situations  the  natural  decomposition  of  a  system 
into  modules  introduces  cyclic  dependencies,  which  cannot  be  expressed  in  a  purely  hierarchical  formalism. 
The  only  solution  is  to  consolidate  mu tu ally-dependent  fragments  into  a  single  module,  which  partially 
undermines  the  very  idea  of  modular  organization. 

In  response  several  authors  have  proposed  linguistic  mechanisms  to  support  noii-hierarchical  modular 
decomposition.  Recent  examples  include:  Sirer,  et  al.  extension  of  Modula-3  with  a  “cross-linking”  mecha¬ 
nism  [17];  Flatt  and  Felleisen’s  extension  of  their  MzScheme  language  with  cyclically-dependent  “units”  [6]; 
Duggan  and  Sourelis’s  “mixin  modules”  that  extend  the  Standard  ML  module  system  with  a  special  “mixlink” 
construct  for  integrating  mutually-dependent  structures  [4,  5];  and  Ancona  and  Zucca’s  algebraic  formalism 
for  mixin  modules  [2].  Each  of  these  proposals  seeks  to  address  the  problem  of  cyclic  dependencies  in  a 
module  system,  but  each  does  so  in  a  slightly  different  way.  For  example,  Flatt  and  Felleisen’s  formalism 
does  not  address  the  critical  issue  of  controlling  propagation  of  type  information  across  module  boundaries. 
Duggan  and  Sourelis’s  framework  relies  on  a  syntactic  transformation  that,  in  effect,  coalesces  the  code  of 
mutually-dependent  modules  into  a  single  module.  It  is  not  clear  what  are  the  fundamental  ideas,  nor  is  it 
clear  how  to  integrate  the  various  aspects  of  these  proposals  into  a  full-featured  module  system. 

It  is  natural  to  ask:  what  is  a  recursive  module?  We  propose  to  address  this  question  in  the  framework 
of  type  theory,  which  has  proved  to  be  a  powerful  tool  for  both  the  design  and  implementation  of  module 
systems.  We  conduct  our  analysis  in  the  context  of  the  “phase  distinction”  module  formalism  introduced 
by  Harper,  Mitchell,  and  Moggi  [9]  (hereafter,  HMM).  The  phase  distinction  calculus  provides  a  rigorous 
account  of  higher-order  modules  (supporting  hierarchy  and  parameterization)  in  a  framework  that  makes 
explicit  the  critical  distinction  between  the  static,  or  compile-time,  part  of  a  module  and  the  dynamic,  or 
run-time,  part.  This  calculus  has  proved  to  be  of  fundamental  importance  to  the  implementation  of  higher- 
order  modules,  as  evidenced  by  its  use  in  Shao’s  FLINT  formalism  used  in  the  SML/NJ  compiler  [15]  and 
in  the  TIL/ML  compiler  [18]. 

Our  analysis  proceeds  in  two  stages.  First  we  consider  a  straightforward  extension  of  the  phase  distinction 
calculus  with  a  notion  of  recursive  (self-referential)  module.  An  interpretation  of  this  new  construct  is 
provided  by  an  interpretation  of  it  into  the  primitive  module  formalism  of  the  phase  distinction  calculus. 
This  interpretation  renders  the  compile-time  part  as  a  recursive  type  and  the  run-time  part  as  a  recursive 
function,  as  might  be  expected.  In  essence  a  recursive  module  is  just  a  convenient  way  of  introducing 
recursive  types  and  functions. 

Unfortunately  this  simple-minded  extension  does  not  go  far  enough  to  be  of  much  practical  use.  As 
Duggan  and  Sourelis  have  observed  [5] ,  it  is  of  critical  importance  for  most  practical  examples  that  the  type 
equations  that  hold  of  a  recursive  module  be  propagated  into  the  definition  of  the  recursive  module  itself. 
In  essence  the  definitions  of  the  type  components  of  a  recursive  module  must  be  taken  to  be  the  types  that 
they  will  eventually  turn  out  to  be  (!)  once  the  recursive  declaration  has  been  processed.  Accounting  for  this 
“forward  reference”  is  the  core  contribution  of  our  work.  We  introduce  a  new  form  of  signature  (interface) 
for  recursive  modules,  called  a  recursively- dependent  signature^  that  allows  us  to  capture  the  required  type 
identities  during  type  checking  of  a  recursive  module  binding.  This  significantly  increases  the  expressive 
power  of  the  recursive  module  formalism,  and  is,  we  assert,  of  fundamental  importance  to  the  very  idea  of 
recursive  modules. 
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2  Type-Theoretic  Framework 

We  begin  by  presenting  the  framework  in  which  we  conduct  our  analysis.  We  will  conduct  our  examples  using 
an  informal  external  language  closely  modeled  after  the  syntax  of  Standard  ML.  The  external  language  is  then 
elaborated  into  the  type-theoretic  internal  language  that  we  describe  below.  We  will  treat  the  elaboration 
process  informally,  illustrating  it  by  examples.  Details  of  how  elaboration  may  be  formalized  appear  in 
Harper  and  Stone  [10]. 

Our  internal  language  is  an  extension  of  the  phase  distinction  calculus  of  Harper,  Mitchell,  and  Moggi  [9]. 
The  language  consists  of  two  main  components:  a  core  calculus^  a  predicative  variant  of  Girard^s  and  a 
structure  calculus^  extending  the  core  language  with  a  primitive  module  construct  without  explicit  mecha¬ 
nisms  for  hierarchy  {e,g.,  substructures)  or  parameterization  {e.g.^  functors).  Primitive  modules  consist  of 
a  static,  or  compile-time,  part  containing  the  type  constructors  of  the  module,  together  with  a  dynamic, 
or  run-time,  part  containing  the  executable  code  of  the  module.  This  separation  is  known  as  the  phase 
distinction.  An  important  property  of  the  formalism  is  that  the  phase  distinction  is  maintained,  even  in  the 
presence  of  higher-order  (and,  as  we  shall  see,  recursive)  module  constructs. 

The  main  result  of  HMM  is  that  higher-order  module  constructs  are  a  definitional  extension  of  the 
primitive  structure  calculus.  In  other  words  higher-order  constructs  are  already  present  in  the  primitive 
structure  calculus  in  the  sense  that  they  may  be  defined  in  terms  of  existing  constructs.  (This  interpretation 
may  be  thought  of  as  a  compilation  strategy  for  higher-order  modules,  and  indeed  this  fact  has  been  exploited 
in  the  FLINT  [15]  and  TIL  [18]  compilers.)  This  means  that  we  need  not  explicitly  discuss  higher-order 
module  constructs  in  this  paper,  but  rather  appeal  to  HMM  for  a  detailed  discussion  of  their  implicit 
presence. 

To  support  the  extension  with  recursive  modules  we  enrich  the  core  phase  distinction  calculus  with  these 
additional  constructs: 

1.  Singleton  and  dependent  kinds  to  allow  expression  of  type  sharing  information  in  signatures.  Related 
formalisms  for  expressing  type  sharing  information  are  given  by  Harper  and  Lillibridge  [7]  and  Leroy 
[11], 

2.  A  fixed  point  operation  for  building  collections  of  mutually-recursive  type  constructors.  These  recursive 
constructors  are  definitionally  equal  to  their  unrollings.  We  term  such  constructors  equi-recursive^  to 
distinguish  them  from  the  more  conventional  iso-recursive  constructors,  in  which  conversions  between 
the  constructors  and  their  unrollings  must  be  mediated  by  the  explicit  use  of  an  isomorphism.  We 
discuss  the  interplay  of  equi-  and  iso-recursive  constructors  in  Section  5. 

3.  A  fixed  point  operation  for  building  collections  of  mutually-recursive  functions.  As  will  become  appar¬ 
ent  later  on,  we  cannot  (as  in  SML)  limit  this  operation  to  collections  of  explicit  lambda  abstractions. 
Instead  we  formalize  a  notion  of  valuability  (indicating  terminating  expressions)  and  a  corresponding 
notion  of  total  function,  essentially  as  in  Harper  and  Stone  [10],  but  with  the  additional  idea  that 
recursively-defined  variables  are  not  considered  valuable  within  the  body  of  their  definitions,  but  are 
considered  valuable  in  their  subsequent  scope. 

In  subsequent  sections  of  this  paper,  we  will  further  augment  our  structure  calculus  with  various  constructs 
for  recursive  modules,  and  then  show  how  those  constructs  can  be  reduced  to  the  elementary  constructs  . 
discussed  in  this  section. 

2.1  The  Core  Calculus 

The  core  phase  distinction  calculus  contains  four  syntactic  classes:  kinds,  type  constructors  (or  just  “con¬ 
structors”),  types,  and  terms.  As  usual,  types  classify  terms  and  kinds  classify  constructors.  The  construc¬ 
tors  provide  a  lambda  calculus  for  constructing  types.  The  syntax  of  the  core  calculus  appears  in  Figure 
1.  We  shall  consider  expressions  that  differ  only  in  the  names  of  bound  variables  to  be  identical,  and  write 
capture- avoiding  substitution  of  E  for  X  in  E'  as  E^[E/X]. 

The  kinds  include  the  kind  T  of  all  monotypes;  the  trivial  kind  1,  containing  only  the  constructor 

dependent  products  na:«:i.Ac,  containing  constructor  functions  from  aci  to  K2  where  a  stands  for  the 
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Figure  1:  The  Core  Calculus 
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=  Q(7ri(c)  :  Ki)  X  Q(7r2(c)  :  K2) 


Figure  2:  Higher-Order  Singletons 


argument  and  may  appear  free  in  /C2;  and  dependent  sums  I]a:«:i./C2,  containing  constructor  pairs  built  from 
Ki  and  K2  (respectively)  where  a  stands  for  the  left-hand  member  and  may  appear  free  in  ac2.  As  usual,  if 
a  does  not  appear  free  in  K2^  we  write  Ki  K2  for  na:«:i.«:2  and  ki  x  K2  for  EQf:«:2-«2- 

Finally,  for  any  constructor  c  with  kind  T,  the  singleton  kind  Q(c)  contains  monotypes  definitionally 
equal  to  c.  Thus,  if  c  has  kind  Q(c'),  the  calculus  permits  the  deduction  of  the  equation  c  =  :T,  Singleton 

kinds  provide  a  mechanism  for  expressing  type  sharing  information  [7,  11].  Although  singleton  kinds  exist 
only  for  monotypes,  they  may  be  used  in  conjunction  with  higher  dependent  kinds  to  express  higher-order 
sharing  information.  For  instance,  if  c  has  kind  HaiT,  Q{list{a)),  it  follows  that  c  =  list  :  T  T.  The 
definition  in  Figure  2  generalizes  this  idea.^ 

The  type  constructors  are  largely  standard.  The  trivial  type  1  contains  the  trivial  term  The  types 
Cl  — )■  C2  and  Cl  C2  are  the  types  of  total  and  partial  functions  from  ci  to  C2  and  are  discussed  in  more  detail 
below.  The  equi-recursive  constructor  fia:K.c[a]  is  is  a  fixed  point  of  the  equation  a  =  c[a].  Thus  pa:K.c[a] 
is  equal  to  its  unrolling  c[fia:Kx[a]].  This  is  in  contrast  to  the  somewhat  more  conventional  iso-recursive 
formulation,  where  conversions  between  the  two  must  be  mediated  by  explicit  operations.  In  Section  5  we 
discuss  how  to  simplify  the  type  theory  to  use  only  iso-recursive  constructors. 

Note  that  there  is  a  subtle  interaction  between  recursive  constructors  and  singleton  kinds.  Since  the  con¬ 
structor  fjLa’.KX  has  kind  /c,  it  follows  that  fia:Q{c)x'  =  c.  Thus,  although  paiT.a  is  a  vacuous,  uninhabited 
type  (as  usual),  the  deceptively  similar  type  pa:Q{±iit).a  is  equal  to  int. 

The  final  construct,  fix{x:(rx)  at  the  term  level,  allows  the  definition  of  recursive  values.  However,  to 
achieve  conservativity  over  ML,  we  wish  to  prevent  the  definition  of  cyclic  data  structures  such  as  fix{x  : 
int  list.  1 :  ix)^  which  cannot  be  defined  in  ML.^  We  do  this  by  imposing  a  value  restriction  on  the  bodies  of 
recursive  definitions.  The  calculus  contains  judgements  F  h  e  J.  (7  asserting  that  e  has  type  cr  and  terminates 
without  computational  effects.  (In  the  present  setting,  the  only  computational  effect  is  nontermination.) 
With  this  so-called  value  restriction  in  place,  the  formation  rule  for  recursive  values  is: 


T[x  'I  a]h  e  ia  T  h  cr  type 
T  h  fix{x:ax)  :  cr 


{x  ^  Dom(r)) 


This  rule  is  read:  fix{x:a.e)  has  type  cr  if  e  terminates  with  type  cr  under  the  assumption  that  x  has  type 
(7  but  cannot  be  taken  as  valuable.  This  rules  out  the  cyclic  list  proposed  above,  since  1:  is  not  valuable 

^Note  that  Q(c  :  k)  is  not  defined  when  k  is  a  singleton  or  dependent  sum  kind.  This  does  not  change  the  expressive  power 
of  this  construct  and  is  necessary  to  obtain  some  desirable  properties,  for  instance  that  Q{c  :  k)  is  a  subkind  of  k,  and  that  k 
is  uniquely  determined  by  Q(c  :  «). 

^To  achieve  conservativity  over  ML,  we  will  also  need  to  eliminate  equi-recursive  types  in  favor  of  iso- recursive  types.  We 
discuss  this  in  Section  5. 
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Figure  3:  The  Structure  Calculus 


unless  X  is  valuable.  In  fact,  the  value  restriction  implies  that  all  appearances  of  x  must  be  guarded  by 
(z.e.,  within  the  body  of)  a  lambda  abstraction;  lambda  abstractions  are  always  valuable,  regardless  of  the 
state  of  their  free  variables.  As  in  Harper  and  Stone  [10],  the  collection  of  valuable  expression  is  enlarged  by 
including  a  type  for  total  (pure)  functions,  such  as  cons  (: :).  The  application  of  a  valuable  total  function 
to  a  valuable  argument  is  considered  valuable.  Total  functions  are  considered  to  be  types,  but  not  type 
constructors,  in  order  to  prevent  their  erroneous  use  in  conjunction  with  recursive  types. 

2.2  The  Structure  Calculus 

Atop  the  core  calculus  we  erect  a  structure  calculus,  exactly  as  in  HMM.  To  review,  we  add  two  syntactic 
classes,  one  for  flat  signatures  and  one  for  flat  structures  (Figure  3).  Structures  are  pairs  [c,  e]  of  constructors 
and  terms.  The  left-hand  component  is  referred  to  as  the  compile-time  (or,  static)  component,  and  the 
right-hand  component  is  referred  to  as  the  run-time  (or,  dynamic)  component.  Signatures,  which  classify 
structures,  have  the  form  [aiK^a],  where  a  stands  for  the  compile-time  component  and  may  appear  free  in 
(T.  The  structure,  [c,  e]  has  kind  [arAc,  cr]  if  c  has  kind  k  and  e  has  type  a[c/a].  Often  we  will  write  [a  =  c,  e] 
as  shorthand  for  [c,  e[c/a]].  We  also  add  constructor  and  term  constructs  Fst{s)  and  snd{s)  for  extracting 
the  first  and  second  components  out  of  structures  named  by  variables.  We  will  occasionally  treat  these 
constructs  as  variables  and  allow  substitution  for  them. 

The  structure  calculus  shows  an  explicit  phase  distinction  between  compile-time  and  run-time  expres¬ 
sions  [9,  3].  Static  expressions  may  be  separated  from  dynamic  ones,  and  static  ones  will  never  depend  on 
dynamic  ones.  This  ensures  that  programs  may  be  typechecked  without  the  need  to  execute  any  run-time 
code. 

HMM  show  that  higher-order  modules  can  be  reduced  to  the  simple  structure  calculus  given  here.  There¬ 
fore  we  will  omit  explicit  discussion  of  higher-order  modules,  without  any  loss  of  generality.  In  this  paper, 
we  show  how  recursive  modules  may  similarly  be  reduced  to  the  structure  calculus  given  here.  In  so  doing, 
we  will  show  that  despite  the  apparent  intertwining  of  static  and  dynamic  expressions  in  recursive  modules, 
that  the  phase  distinction  can  be  preserved,  just  as  HMM  showed  for  higher-order  modules. 

3  Opaque  Recursive  Modules 

We  begin  our  examination  by  considering  what  we  call  “opaque”  recursive  modules.  These  will  prove  to 
insufficiently  expressive  for  most  applications,  but  they  will  serve  to  illustrate  the  main  ideas  and  motivate 
the  more  complex  machinery  in  the  next  section. 

In  the  (informal)  external  language,  we  write  an  opaque  recursive  module  definition  as: 

structure  rec  S  :>  SIG  =  struct  ...  end 

The  structure  variable  S  is,  of  course,  permitted  to  appear  free  within  the  structure’s  body.  The  signature 
SIG  then  expresses  all  the  information  that  is  known  about  S  in  the  body  or  in  the  subsequent  code.  (We 
borrow  the  symbol  from  Standard  ML  1997  [13]  to  suggest  this  opacity.)  In  particular,  the  opaque 
signature  obscures  the  fact  that  the  types  in  S  are  recursively  defined. 

This  declaration  construct  corresponds  to  a  module  fixed  point  operation  in  the  internal  language,  written 
fix{s:S.M)>  For  reasons  similar  to  those  in  the  previous  section,  we  must  impose  a  value  restriction  on  M, 


T  \-  K  kind  r[a  :  k]^  a  type  r[Qf  :  k]\-  c  :  k  T[a  :  Ac][a^  (r]h  e  a  (ax^  Dom(r)) 

T  \-  fix{s:[a:K,(T].[c[Fst{s)/a],e[Fst{s)^  snd{s)/a,x]])  [a  =  pa:Kx^fix{x:ax)]  :  [aiK.a]  ^ 


Figure  4:  Phase-Splitting  Recursive  Modules 


resulting  in  the  following  typing  rule: 


r[5  t  5]  h  M  ;  5  T\-  S  sig 
T\-fix{s:S.M)  :S 


{s  ^  Dom(r)) 


Thus,  a  recursive  module  is  valid  if  its  body  (M)  is  valuable  without  assuming  the  recursive  variable  (5)  to 
be  valuable.  If  a  module  M  is  [c,e],  then  M  will  be  valuable  exactly  when  e  is  valuable  {i.e.,  constructors 
are  always  valuable). 

Following  HMM,  we  wish  to  reduce  recursive  modules  to  the  primitive  structure  formalism  by  defin¬ 
ing  fix{s:S.M)  in  terms  of  primitive  constructs.  We  will  do  this  by  phase-splitting  recursive  modules 
into  run-time  and  compile-time  components.  Suppose  S  is  the  signature  [a:K,a]  and  M  is  the  structure 
[c(F5f(s)),  e(F’5^(s),  5nd(s))].  Then  we  can  interpret  fix{s:S.M)  by  wrapping  the  static  and  dynamic  compo¬ 
nents  in  fixed  point  expressions: 


fix(s:S.M)  =  [a  =  pa:K.c{a)jfix{x  :  cr.e(a,  a:))] 

This  definition  is  formalized  in  the  type  theory  by  the  equational  rule  in  Figure  4.  This  rule  parallels  the 
non-standard  equational  rules  from  HMM,  and  illustrates  that  recursive  modules  are  already  present  in  the 
underlying  calculus.  In  particular,  the  formation  rule  for  recursive  modules  given  above  follows  from  the 
definition  and  need  not  appear  as  a  primitive  rule. 


3.1  Trouble  with  Opacity 

The  opaque  interpretation  of  recursive  modules  is  pleasantly  simple,  but  unfortunately,  it  is  not  sufficiently 
expressive  to  support  some  desired  programming  idioms.  One  common  application  of  recursive  modules  is 
to  break  up  mutually  recursive  data  types.  As  a  particularly  simple  (though  somewhat  contrived)  example, 
consider  an  implementation  of  integer  lists  as  a  recursive  module  that  defers  recursively  to  itself  for  an 
implementation  of  the  tail: 

signature  LIST  = 
sig 

type  t 

val  nil  :  t 

val  null  :  t  ->  bool 

val  cons  :  int  *  t  ->  t 

val  uncons  :  t  ->  int  *  t 

end 
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structure  rec  List  :>  LIST  = 
struct 

datatype  t  =  NIL  I  CONS  of  int  ♦  List.t 

val  nil  =  NIL 

fun  null  NIL  =  true 

I  null  (CONS  „)  =  false 
fun  cons  (n  :  int,  1  :  t)  = 
case  1  of 

NIL  =>  CONS  (n.  List. nil) 

I  CONS  (n*  :  int,  1*  :  List.t)  => 

CONS  (n.  List. cons  (n\  lO) 
fun  uncons  NIL  =  raise  Fail 

I  uncons  (CONS  (n  :  int,  1  :  List.t))  = 
if  List. null  1  then 
(n,  NIL) 
else 

(n,  CONS  (List. uncons  1)) 

end 


This  implementation  typechecks  properly,  and  it  is  observationally  equivalent  to  a  conventional  imple¬ 
mentation.  However,  intensionally  it  is  very  different,  because  each  use  of  cons  and  uncons  must  traverse 
the  entire  list,  leading  to  poor  behavior  in  practice.  A  more  direct  implementation  is  impossible  because  the 
opacity  of  List.t  precludes  any  knowledge  that  List.t  is  the  same  as  t. 

Some  other  examples  cannot  be  written  in  the  opaque  case  at  all.  For  example,  consider  an  implemen¬ 
tation  of  abstract  syntax  trees  using  mutually  dependent  modules  for  expressions  and  declarations.  These 
modules  interact  with  each  other  through  the  let  expression,  which  contains  a  declaration,  and  the  val  dec¬ 
laration,  which  contains  an  expression.  To  optimize  a  common  case,  the  expression  code  includes  a  function 
for  let  val  expressions  that  defers  to  the  declaration  code  to  build  a  declaration: 

signature  EXPR  = 
sig 

type  exp 
type  dec 

val  make_let  :  dec  *  exp  ->  exp  (♦  let  DEC  in  EXP  end  ♦) 
val  maJke_let_val  :  identifier  *  exp  *  exp  ->  exp 

(*  let  val  ID  =  EXP  in  EXP  end  *) 


end 

signature  DECL  = 
sig 

type  dec 
type  exp 

val  make_val  :  identifier  ♦  exp  ->  dec  (♦  val  ID  =  EXP  *) 


end 
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structure  rec  Expr  :>  EXPR  = 
struct 

datatype  exp  =  LET  of  Decl.dec  *  exp  I  ... 
type  dec  “  Decl.dec 


fun  make_let  (d  :  dec,  e  :  exp)  =  LET  (d,  e) 
fun  make^let^val  (id  :  identifier,  el  :  exp,  e2  :  exp)  = 
let  val  d  =  Decl.make_val  (id,  el)  (*  type  error!  el 
in 


LET  (d,  e2) 


exp  ^  Decl.exp  *) 


end 

and  Decl  :>  DECL  = 
struct 

datatype  dec  =  ... 
type  exp  =  Expr. exp 


end 

Unfortunately,  this  code  does  not  typecheck.  The  call  to  make.val  within  makeJ.et_val  expects  an  argument 
with  type  Decl.exp,  which,  because  of  the  opacity  of  Decl,  is  not  known  to  be  the  same  type  as  exp,  the 
type  of  its  actual  argument  el.  The  type  error  occurs  because  the  type  system  cannot  tell  that  exp  is  equal 
to  Decl .  exp,  even  though  an  examination  of  the  recursive  definition  reveals  that  it  is  actually  true. 


4  Transparent  Recursive  Modules 

The  difficulties  described  in  the  previous  section  can  be  traced  to  the  inability  to  track  suflScient  type 
information  in  the  context  of  a  recursive  structure  binding.  In  the  abstract  syntax  example  the  proposed 
binding  fails  to  typecheck  because  within  the  definition  of  Expr  it  is  not  apparent  that  the  type  exp  is 
equivalent  to  the  type  Decl.exp,  even  though  this  equation  will  be  valid  once  the  recursive  binding  is  in 
force.  Similarly,  within  the  definition  of  Decl  it  is  not  apparent  that  the  type  dec  is  equivalent  to  the  type 
Expr  .dec,  which  will  turn  out  to  be  true  once  the  binding  is  in  force.  Were  this  equation  available  while  the 
definitions  of  Expr  and  Decl  are  being  typechecked,  the  entire  declaration  would  be  seen  to  be  valid,  and 
these  very  equations  would  hold  true  afterwards.  Similarly,  the  inefficiency  of  the  suggested  implementation 
of  lists  may  be  traced  to  the  failure  to  identify  the  types  List.t  and  t  inside  the  definition  of  List. 

What  is  needed  is  a  means  of  propagating  the  type  equations  that  will,  upon  completion  of  the  recursive 
binding,  turn  out  to  be  true  of  the  recursively-defined  structures,  into  the  scope  of  the  recursive  definition 
itself.  This  makes  it  possible  to  exploit  the  recursive  definitions  of  the  types  involved  during  typechecking 
of  the  dynamic  part  of  the  recursively-defined  modules,  leading  to  a  much  more  flexible  and  useful  notion  of 
recursive  module.  In  effect  we  are  exploiting  the  phase  distinction  by  solving  the  static  recursion  equations 
prior  to  checking  the  dynamic  typing  conditions  of  the  module,  but  we  are  achieving  this  using  a  one-pass 
algorithm. 

How  is  this  additional  type  sharing  information  to  be  propagated?  The  obvious  solution  is  to  add  the 
appropriate  equations  to  the  signatures  of  the  modules  involved.  In  the  case  of  the  abstract  syntax  example 
this  may  be  achieved  as  follows: 

structure  rec  Expr  :  EXPR  where  type  dec  =  Decl.dec  =  ... 

and  Decl  :  DECL  where  type  exp  =  Expr. exp  =  . . . 

Similarly,  in  the  list  example  we  may  propagate  the  required  information  as  follows: 
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structure  rec  List  :  sig 

datatype  t  “  NIL  I  CONS  of  int  *  List .t 


val  cons  :  int  *  t  ->  t 
val  uncons  :  t  ->  int  *  t 
end  =  . . . 

The  underlined  phrases  indicate  free  occurrences  of  structure  variables  that  are  introduced  by  the  recursive 
structure  binding.  Since  the  signatures  of  the  recursively- defined  structure  variables  depend  on  the  structures 
themselves,  we  call  these  signatures  recursively- dependent  signatures,  or  rds^s  for  short. 

The  purpose  of  a  recursively-dependent  signature  is  to  express  the  sorts  of  recursive  type  equations  that 
are  required  to  recover  the  ill-formed  examples  of  the  preceding  section.  Let  us  now  revisit  those  examples 
to  see  how  rds’s  are  used  to  resolve  the  difficulties  those  examples  raise.  With  the  addition  of  the  type 
definitions  given  above,  the  abstract  syntax  example  from  Section  3  is  now  type  correct  since  the  equations 
Expr.dec  =  Decl.dec  and  Decl.exp  =  Expr.exp  are  propagated  into  the  bindings  of  the  structures  Expr 
and  Decl.  This  is  all  that  is  required  for  the  code  given  in  Section  3  to  be  type  correct. 

The  list  example  is  handled  similarly,  but  also  raises  a  delicate  point  about  recursive  datatypes  in  the 
context  of  a  recursive  structure  binding.  Using  a  recursively-dependent  signature  it  is  possible  to  give  an 
implementation  of  lists  with  constant-time  primitive  operations  as  follows: 

structure  rec  List  :  sig 

datatype  t  =  NIL  |  CONS  of  int  *  List.t 


val  cons  :  int  ♦  t  ->  t 
val  uncons  :  t  ->  int  *  t 
end  = 


struct 

datatype  t  =  NIL  I  CONS  of  int  *  List.t 


fun  cons  (n  :  int,  1  :  t)  =  CONS  (n,  1) 
fun  uncons  NIL  =  raise  Fail 

I  uncons  (CONS  (n,  1))  =  (n,  1) 

end 

The  effect  of  the  recursively-dependent  signature  in  this  example  is  to  ensure  that  the  implementation  type 
of  the  recursive  datatype  List.t  coincides  with  the  implementation  type  of  the  type  t  within  the  body  of  the 
definition.  In  other  words  we  impose  a  structural,  or  transparent,  interpretation  of  recursive  datatypes  within 
the  scope  of  a  recursive  structure  binding,  rather  than  the  more  familiar  nominal,  or  opaque,  interpretation 
used  in  Standard  ML.  In  type-theoretic  terms  the  rds  ascribed  to  List  is  tantamount  to  a  signature  that 
transparently  defines  the  type  t  to  be  the  underlying  iso-recursive  type  of  the  recursive  datatype.  We  note, 
however,  that  this  interpretation  can  be  limited  to  the  recursive  structure  binding  itself,  and  need  not 
propagated  into  the  subsequent  scope  of  the  binding.  In  type-theoretic  terms  the  elaborator  must  “seal”  the 
structure  with  an  opaque  signature  hiding  the  implementation  type  of  List.t  after  the  binding  has  been 
processed. 

In  order  to  maximize  the  propagation  of  type  information  we  will  assume  that  the  elaborator  implicitly 
renders  every  recursively  dependent  signature  to  be  fully  transparent  in  the  sense  that  every  type  component 
is  given  by  an  explicit  type  definition.  In  the  present  case  of  recursive  module  definitions,  the  elaborator  can 
produce  the  needed  fully  transparent  signature  by  inspection  of  the  module  being  defined.  (This  is  always 
possible  since  we  are  assuming  a  transparent  interpretation  of  datatypes.) 

As  emphasized  by  Duggan  and  Sourelis  [5],  it  is  important  in  practice  to  consider  recursive  structure 
bindings  whose  right-hand  sides  are  applications  of  previously-defined  functors  (parameterized  modules). 
A  naive  attempt  to  do  so  runs  afoul  of  the  opacity  problem  once  again,  as  demonstrated  by  the  following 
“functorized”  version  of  the  list  example.  Specifically,  we  wish  to  define  the  List  structure  as  follows: 
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structure  rec  List  :  sig 

datatype  t  =  NIL  1  CONS  of  int  *  List.t 
end  = 

BuildList  (structure  List  =  List) 

where  the  functor  BuildList  abstracts  the  efficient  implementation  of  lists  as  follows: 

functor  BuildList  (structure  List  :  LIST)  =  ...  as  above  ... 

However,  the  efficient  implementation  of  lists  no  longer  typechecks  since  the  assumption  governing  the 
parameter  List  of  BuildList  does  not  propagate  the  critical  recursive  type  equation,  as  was  observed  by 
Duggan  and  Sourelis  (for  an  essentially  similar  example).  The  solution  is  to  use  a  recursively-dependent 
signature  for  the  functor  parameter,  as  follows: 

functor  BuildList  (structure  rec  List  :  sig 

datatype  t  =  NIL  I  CONS  of  int  ♦  List.t 


end)  = 

...  as  above  ... 

Here  again  we  assume  a  structural  interpretation  of  datatypes  that  occur  within  an  rds,  which  is  consistent 
with  the  structural  signature  matching  rule  for  functor  applications  in  Standard  ML. 

Again,  the  elaborator  must  render  rds’s  fully  transparent.  For  recursive  module  definitions  that  was 
easily  done  by  inspection  of  the  definition.  However,  when  an  rds  is  the  signature  of  a  functor  argument,  the 
argument  is  unavailable  for  such  inspection.  In  order  to  render  such  rds’s  fully  transparent,  the  elaborator 
must  name  any  abstract  types  within  the  signature  and  pull  them  out.  (A  similar  device  is  used  by  the 
generative  stamps  in  the  Definition  of  Standard  ML  [13].)  For  example,  the  signature 

rec  S  :  sig 

type  t 

type  u  =  S.u  “>  t 

end 

is  rewritten  by  introducing  a  type  definition  for  t  setting  it  equal  to  an  abstract  type  that  is  defined  outside 
the  rds.  The  resulting  signature  is  acceptable  because  the  rds,  which  now  lies  within  an  outer  signature,  is 
fully  transparent: 

sig 

type  t^ 

structure  rec  S  : 
sig 

type  t  =  t' 
type  u  =  S.u  ->  t 

end 

end 

4.1  Formalization  of  Recursively-Dependent  Signatures 

The  addition  of  recursively-dependent  signatures  to  the  phase  distinction  calculus  is  performed  in  two  stages. 
First,  we  extend  the  syntax  of  signatures  with  the  recursively  dependent  form,  which  we  write  ps.Sj  and 
extend  the  signature  formation  and  equivalence  rules  with  rules  governing  this  new  form.  We  also  extend  the 
module  formation  rules  to  include  introductory  and  eliminatory  rules  for  recursively-dependent  signatures. 
Second,  we  show  that  this  enrichment  of  the  structure  calculus  may  be  interpreted  into  the  original  structure 
calculus  (over  the  extended  core  language  described  in  Section  2)  by  exhibiting  an  equation  between  rds’s 
and  ordinary  signatures. 
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r  h  /c  kind  r[a  :  k]  h  (T[a/ Fst[s)\  type  T[^  :  k]\-  S{c  :  k)  kind 
ps.[a:Q{c[Fst{s) / /3]  :  k),(t]  =  [a:Q((///?:/c.c)  :  K),(T[a/ Fst{s)]] 

Figure  5:  Phase-Splitting  Recursively- Dependent  Signatures 


Informally,  the  recursively-dependent  signature  ps.S  contains  those  modules  M  that  belong  to  5  where 
s  may  appear  free  in  S  and  stands  for  M.  In  other  words,  M  belongs  to  ps.S  when  M  belongs  to  S[M/s]. 
Formally,  rds’s  adhere  to  the  following  introductory  and  eliminatory  rules: 


r  h  M  :  S[M/s]  r  h  ps.S  sig  F  h  M  :  ps.S 
r  h  M  :  ps.S  r  h  M  :  S[M/s] 


As  discussed  previously,  in  the  rds  ps.S  we  require  that  the  static  component  of  5  be  fully  transparent,  that 
is,  that  it  completely  specify  the  identity  of  its  static  component  using  singleton  kinds.  Thus,  in  order  for  an 
rds  ps.S  to  be  well-formed,  S  must  be  fully  transparent  and  well-formed  under  the  assumption  that  s  has 
signature  S",  where  5'  is  obtained  from  S  by  stripping  out  the  singleton  kinds  specifying  the  identity  of  the 
static  component.  Formally,  rds’s  have  the  following  formation  rule: 


r  h  5  sig  T[s  :  5]  h  [a:Q{c  :  ac),  cr]  sig 
r  h  ps.[a:Q{c  :  /c),  cr]  sig 


(S 


[aiKj  ala / Fst{s)]]) 


As  with  the  recursive  modules  of  Section  3,  we  wish  to  reduce  recursively-dependent  signatures  to  primitive 
constructs  of  the  structure  formalism.  We  do  this  by  wrapping  the  compile-time  component  of  the  rds  in  a 
fixed  point  expression,  and  by  redirecting  recursive  references  in  the  run-time  component: 

ps.[a:Q{c{Fst{s))  :  K),(r{o',  Fst{s))]  =  [a:Q{{pl3:K.c{/3))  :  /c),(7(a,a)] 

In  the  second  underlined  fragment,  recursive  references  using  Fst{s)  are  redirected  to  use  a.  The  interesting 
part  is  the  first  underlined  fragment:  Suppose  [c\e]  is  a  prospective  member  of  the  rds.  The  rds  dictates 
that  c'  :  Q{c{F)  :  k)  and  consequently  that  F  =  c(c')  :  k.  Therefore,  F  may  be  taken  to  be  p/3:k.c{/3)  as 
provided  by  the  first  underlined  fragment. 

This  definition  is  formalized  in  the  type  theory  by  the  equational  rule  in  Figure  5.  As  in  Section  3, 
this  rule  illustrates  that  recursively-dependent  signatures  are  already  present  in  the  underlying  calculus.  In 
particular,  the  introductory  and  eliminatory  rules  given  above  follow  from  the  definition  and  need  not  appear 
as  primitive  rules. 


5  Future  Work 

Purely  hierarchical  module  systems,  such  as  the  Standard  ML  module  system,  may  be  criticized  on  the 
grounds  that  they  lack  adequate  support  for  cyclic  dependencies  among  components.  In  such  languages 
interdependent  components  must  be  consolidated  into  a  single  module,  which  can  prevent  decomposition 
of  a  system  into  “mind-sized”  fragments.  Several  authors  (including  Duggan  and  Sourelis  [4,  5]  and  Flatt 
and  Felleisen  [6])  have  proposed  module  systems  that  better  support  such  cyclic  dependencies  among  units. 
With  at  least  two  different  proposals  for  recursive  modules  in  hand,  it  is  natural  to  ask  “what  is  a  recursive 
module?”  We  provide  an  answer  to  this  question  in  the  form  of  a  type-theoretic  analysis  of  recursive  modules 
based  on  the  “phase  distinction”  calculus  of  higher-order  modules  [7] , 

Specifically,  we  propose  an  extension  of  the  phase  distinction  calculus  with  a  new  form  of  recursive  module 
and  a  new  form  of  signature,  called  a  recursively-dependent  signature.  Following  the  paradigm  of  the  phase 
distinction  interpretation  of  higher-order  modules,  we  demonstrate  the  sensibility  of  this  extension  by  giving 
an  interpretation  of  it  into  a  pure  calculus  of  structures  (without  explicit  recursive  module  constructs). 
This  interpretation  demonstrates  that  in  a  precise  sense,  recursive  modules  are  already  present  in  the  pure 
structure  calculus.  As  in  the  case  of  higher-order  modules,  this  is  the  key  to  implementing  recursive  modules 
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in  a  type-passing  compiler  such  as  Shao’s  FLINT-based  implementation  of  Standard  ML  [15]  or  Morrisett,  et 
aL  TIL  compiler  [18]  —  simply  translate  them  into  the  pure  structure  formalism  using  the  interpretation 
given  here. 

To  make  these  ideas  practical  more  work  remains  to  be  done.  It  is  important  to  demonstrate  that  type¬ 
checking  remains  decidable  in  the  presence  of  recursively-dependent  signatures.  The  central  issue  for  decid¬ 
ability  is  decidability  of  equivalence  for  equi-recursive  constructors  of  higher  kind.  Amadio  and  Cardelli  [1] 
provide  an  algorithm  for  checking  equality  of  equi-recursive  types;  it  is  not  clear  at  present  whether  their 
work  extends  to  higher  kinds.  It  is  also  important  to  consider  a  dynamic  semantics  for  the  extended  language 
and  to  demonstrate  the  soundness  of  the  type  system  for  this  dynamic  semantics.  We  do  not  expect  any 
difficulties  with  this  extension. 

A  natural  question  is  whether  the  reliance  on  equi-recursive  constructors  is  essential  for  supporting 
recursive  modules.  (For  example,  Duggan  and  Sourelis’s  formalism  does  not  rely  on  this  form  of  recursive 
types.)  We  conjecture  that  it  is  not  essential,  based  on  the  following  observations.  Under  the  standard 
type-theoretic  interpretation  of  ML  (see,  for  example,  Harper  and  Mitchell  [8]),  the  implementation  of  a 
recursive  datatype  is  an  iso-recursive  type.  If  we  restrict  recursive  modules  to  datatypes  (as  in  Duggan  and 
Sourelis’  formalism),  and  adopt  the  “transparent”  interpretation  outlined  in  Section  4,  then  equi-recursive 
types  are  completely  eliminable  by  the  translation  into  the  underlying  structure  calculus,  provided  that  we 
adopt  Shao’s  equation  for  iso-recursive  types:^ 

fj,^a.c{a)  =  fi^ax{fi^a.c{a)) 

The  relevance  of  Shao’s  equation  to  the  elimination  of  equi-recursive  types  is  based  on  the  following  ob¬ 
servation.  After  translation  into  the  pure  structure  calculus,  datatypes  in  the  body  of  a  recursive  module 
definition  have  implementation  types  of  the  form 

for  some  constructor  c.  Using  a  bisimilarity  interpretation  of  equality  of  equi-recursive  types,  and  applying 
Shao’s  equation,  we  may  prove  that  this  type  is  equivalent  to  the  type 

/?) 

which  is  a  purely  iso- recursive  type.  This  observation  sheds  light  on  the  nature  of  Duggan  arid  Sourelis’s 
restriction  on  the  recursively  defined  type  components  of  a  mixin  module  to  datatypes,  which  are  implicitly 
iso- recursive.  Strictly  speaking,  this  restriction  is  not  necessary,  but  if  it  were  to  be  adopted,  it  would,  by  the 
observation  above,  allow  the  elimination  of  equi-recursive  types  from  the  internal  language  of  a  type-based 
compiler  for  ML. 


^This  equation  was  introduced  by  Shao  [16]  in  his  FLINT  formalism  in  order  to  support  the  compilation  of  Standard  ML. 
Shao  observed  that  this  equation  is  essential  for  efficiently  compiling  Standard  ML,  even  in  the  absence  of  recursive  modules. 
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A  Type  Theory 

A.l  Core  Calculus 


r  h  AC  kind 


r  h  ACi  =  ac2  kind 


r  h  Ki  <  K2  kind 


r  h  T  kind 

r  h  1  kind 

r  h  c  :  T ype 
r  h  Q{c)  kind 

r  }-  ACi  kind  r[a  :  aci]  h  ac2  kind 

r  h  ACi  kind  Ffa  :  aci]  h  ac2  kind 

- — — - -  (a  0  Dom(r)) 

1  rLa:ACi.AC2  kind 

r  h  T  =  T  kind 

r  H  1  =  1  kind 

r  h  Cl  =  C2  :  Type 
r  h  Q(ci)  =  Q(c2)  kind 

r  h  ACi  =  k[  kind  Pfa  :  aci]  h  ac2  ==  «2  kind  , 

- ; — ; -  (a  ^  Dom(r)) 

r  h  na:ACi.Av2  =  na:ACi.AC2  kind 

Ki  =  k[  kind  r[a  :  aci]  h  ac2  =  ac2  kind  .  ^  ^  . 

- ; — ; -  (a  0Dom(r)) 

r  h  Ea:ACi.AC2  =  EarAcJ-AC^  kind 

r  h  T  <  T  kind 

r  h  1  <  1  kind 

r  h  Cl  =  C2  :  T ype 
P  2(ci)  <  S(c2)  kind 

Phc  :T 

P  1“  Q(c)  <  T  kind 

P  h  AcJ  <  ACi  kind  Pfa  :  acJ]  h  ac2  <  ac2  kind  P[a  :  aci]  h  ac2  kind 

- — — - — - ,  -  (a  ^  Dom(P)) 

P  r  na:ACi.AC2  <  na:Ki.AC2  kind 


Ph 


P  h  c  :  AC 


2  <  na:Ki.AC2  kind 

P  h  ACi  <  Ac'i  kind  P[a  :  aci]  h  ac2  <  ac2  kind  P[a  :  k[ 
P  h  Eq':ki.ac2  <  EarKi-Ac^  kind 


k'i]  I-  K2  kind 

,  ,  , -  (a  i  Dom(r)) 

:ki.K2  kind 
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r  h  ★  :  1 


r  h  Ki  hind  r[a  :  aci]  f-  c  :  K2 
r  1-  AatKi.c  ;  I{a\Ki.K2 


(a  0  Dom(r)) 


r  h  Cl  :  HaiKi  .K2  F  h  C2  :  aci 
r  h  CiC2  :  Av2[c2/a] 


r  h  Cl  :  Avi  r  h  C2  :  AC2[ci/a]  r[a  :  Ki]  h  K2  hind 
r  h  (ci, C2)  :  Ea:ACi.Av2 


(a  0  Dom(r)) 


r  h  c  :  Eq':aci.K2 
r  ;ri  (c)  :  aci 


r  h  c  :  Eo':ki.ac2 
r  h  7r2(c)  :  AC2[7ri(c)/a] 


Fh  1  :T 

F  h  Cl  :  T  F  h  C2  :  T 
F  h  Cl  C2  :  T 

F  h  Cl  :  T  F  h  C2  :  T 
F  h  Cl  X  C2  :  r 


r[a  :  k]  h  c  : 

F  H  na:n.c  :  k 


{a  0  Dom(F)) 


FhciAv'  F1-k'<«:  hind 
F  l-  c  :  AC 


F  h  Xa:Ki.ca  :  Ila:Ki.K2 
F  h  c  :  IlarACi  .AC2 


(a  not  free  in  c) 


F  h  (7ri(c),  7r2(c)}  :  Ea:Ki  .K2 
F  h  c  :  Ea:ACi  .ac2 


F  h  Cl  =  C2  :  AC 

F  h  c  :  K 
F  h  c  =  c  :  K 

r  {-  C2  =  Cl  :  K 

F  H  Cl  ==  C2  :  K 


F  h  Cl  =  C2  :  «  F  h  C2  =  C3  :  AC 

r  h  Cl  =  C3  :  AC 


F  I-  ACi  =  Ac'i  hind  F[a  :  ki]  |-  c  =  c'  :  ac2 
F  h  XaiKi.c  =  Xa:K[,c*  :  na:ACi.K2 


(a  0  Dom(F)) 
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r  h  Cl  =  ci  :  IlarKi  .K2  F  h  C2  =  C2  :  ki 
r  h  C1C2  =  cic2  :  K2[c2/a'] 


T  \-  c\  =  c[  :  K\  r  h  C2  =  C2  :  K2[ci/cv]  r[a  :  «i]  h  K2  kind 
F  I-  {ci,C2)  =  (cl,C2)  :  Ea:Ki.K2 


(a  0  Dom(F)) 


r  h  c  =  :  Ea:Ki  .K2 

F  h  7ri(c)  ==  7ri(c')  :  n\ 


r  F  c  =  :  Tta\Ki.K2 _ 

r  h  7r2(c)  =  7r2(c')  :  K2[7ri(c)/a] 


F  h  Cl  =  ci  :  T  F  h  C2  =  C2  :  T 
F  h  Cl  — ^  C2  =  Cl  C2  :  T 


F  h  Cl  =  c;  :  T  F  h  C2  =  C^  :  T 
F  h  Cl  X  C2  =  ci  X  C2  '  T 


r  \-  K  =  k'  F[a  :  k]  h  c  =  c'  :  « 


F  h  fiaiK.c  =  ^aiK^c'  :  k 

r  h  Cl  =  C2  :  r  \-  k'  <  K  kind 

r  h  Cl  =  C2  :  K 


(a  ^Dom(F)) 


Fhc:  Q{c') 
F  f-  c  =  c'  :  T 


F{-c:  1 
r  h  c  =  ★  :  1 


F  h  Cl  :  Ki  r[a  :  ki]  I-  C2  :  K2 
F  h  (Aa:Ki.C2)ci  =  C2[ci/a]  :  K2[ci/a] 


{a  ^  Doin(F)) 


_ Fhc:  IlaiACi  .K2 _ 

F  h  (AarKi.ca)  =  c  :  Ila:Ki.K2 


(a  not  free  in  c) 


F  h  Cl  :  Ki  F  h  C2  :  k:2  . .  _  ^  2) 
F  h  7rt((ci,C2))  =  Ci  :  m 

_ Fhc:  Ecyr/ci  ,k.2 _ 

F  h  (7ri(c),  7r2(c))  =  c  :  Yla:n\,n2 


F[a  :  k]  h  c  :  K 

F  h  }j,a:K,c  =  c[(^a:K.c)/a]  :  k 


(a  ^  Dom(F)) 


F  h  c  =  c'[c/a]  :  k  F[a  :  k]  h  c^  :  k 
r  h  c  =  fjaiK.c'  :  k 


{a  ^  Dom(F)) 
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r  h  O'  type 


r  h  O'!  =  0-2  type 


r  e  :  a 


The  :T 

The  type 

r  h  O'!  type  T  \-  <T2  type 
r  h  cTi  (72  type 

T  h  <Ti  type  r  h  (72  type 
r  h  (Ji  — ^  0*2  type 


r  h  cTi  type  r  h  0-2  type 
r  h  O’!  X  <72  type 


r[Q'  :  k]\-  a  type 
r  h  Va:«:.<7  type 


((^  ^Dom(r)) 


rh  <7  = 

<7 

^2/pe 

r  h  <72  = 

<7i 

type 

FF-  <71  = 

^^2 

type 

<72  type 

r  f“  <72  = 

n-  <71  = 

<T3 

type 

rhc  = 

:  c' 

:T 

r  h  c  =  c'  type 


r  h  (71  =  <7(  type  r  h  <72  =  0-2  type 
r  H  (7i  — )•  (72  =  (7$  ^  <72  type 

r  h  <Ti  =  (7j  type  r  h  <72  =  0-2  type 
r  h  <7i  <72  =  <7^  <72  type 


r  h  <7i  =  <7^  ^ype  r  h  <72  =  <72  type 
r  h  <7i  X  <72  =  <7^  X  <72  type 


r  h  K  =  r[a  :  «:]  h  <7  =  <7^  type 
r  (-  "ia'.K.a  =  VQ':K^<7'  type 


{a  0  Dom(r)) 


rF7T7<'"’'^'’> 

fTTT^ 


r  h  (7  type  r[x  :  cr]  h  e  4^  <7 
r  h  Aa;:<7.e  :  <7  — )•  <7^ 


(ar  ^  Dom(r)) 
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r  I-  iT  type  r[a;  ;  (t]  h  e  :  cr 
r  h  \x:<T,e  :  cr  <T* 


(x  0  Dom(r)) 


r  h  ei  :  O’  a'  P  h  62  :  (T 
r  h  6162  :  (t' 

r  h  ei  :  (T  — ^  (t'  r  (-  62  :  (T 
r  H  6162  : 

r  h  61  :  (Ti  r  h  62  :  <T2 
r  1”  (61,62)  :  <Ji  X  <T2 


P  h  6  4,  (T 


P  h  6  :  (Ti  X  cr2 
P  1-  7ri(e)  :  <Tt 


(i  =  l,2) 


P  h  K  /i:mc/  P[a  :  k]  h  e  |  (T 
P  h  AaiK.e  :  Mam. a 


(a  ^  Dom(P)) 


P  h  6  :  VaiK.cr  P  h  c  :  K 
P  h  6[c]  :  <T[c/a] 


P  h  <T  type  P[a;  f  1“  6  (j 
P  h  fix{x:(j.e)  :  (T 


(:r  0  Dom(P)) 


Pf-e:<T^  Phcr  =  <T'  fype 

Pl-e:^7 


P  h  a:  4,  (7 


(a;  :  O'  6  P) 


Pl-^;i 


P  h  O'  type  P[a;  :  <j]\-  e  (t 
P  h  \x:(T.e  X  <T 


{x  i  Doin(P)) 


P  h  O'  type  P[a;  :  o']  h  6  :  o' 
P  P  \x\<j.e  4.  O'  — ^  o'^ 


(a:  0  Dom(P)) 


T  Cl  O’  <t'  Pl-e2  4'^ 
P  h  6162  4-  cr' 


P  h  61  I  O'!  P  h  62  i  0'2 

P  P  (61 , 62)  4-  (^2 


P  P  6  4^  O'!  X  0'2 
P  P  7ri{e)  I  (Ti 


(i  =  l,2) 


P  P  K  kind  P[a  :  k]  P  e  4-  cr 
P  P  Aam.e  4<  Ma:K.<r 


(of  ^  Dom(P)) 
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r  h  e  4- Va:«:.fr  F  h  c  :  k 
r  h  e[c]  4.  cr[c/a] 


r  h  e  =  e'  :  (T 


r  I-  O’  type  r[a;  t  |  cr 

r  h  fix{x:cr,€)  i  cr 


{x  ^  Dom(r)) 


T  \-  e  ^  <t'  T  \-  (t  =  a'  type 
r  h  e  4- 


r\-e:a 

r  h  e  =  e  :  <T 

r  h  62  =  ei  :  O' 
rhei=e2:o’ 

r  h  61  =  62  :  O’  ri-e2=e3:o’ 
r  h  61  =  63  :  O’ 


r  h  O'!  =  o’2  type  r[a;  :  O’!]  h  e  =  :  0-2  r[a;  :  o’! ]  h  e  4-  cr2 

r  h  Aa;:o’i.e  =  Xx:a[.e'  :  o’!  — )•  0’2 


{x  i  Dom(r)) 


r  h  O’!  =  0’2  type  r[a;  :  o-i]  h  e  =  e'  :  0’2 
r  h  Aa^ro-i  .6  =  Aa;:o’J  .e^  :  o’!  — ^  o’2 


(x^Dom(r)) 


T  \-  ei  —  e[  :  (T  (t'  F  h  62  =  62  :  o’ 
F  h  6162  =  6162  :  O’' 

F  F  61  =  ei  :  O’  — ^  O’'  F  h  62  =  62  :  o’ 
F  F  6162  =  e'ie2  :  o’' 


F  F  61  =  e'l  :  O’!  F  F  62  =  62  :  o’2 
F  F  (61,62)  =  (e'l, 62)  :  O’!  X  0-2 


F  F  6  =  e'  :  O’!  x  o’2 
F  F  7:i{e)  =  7ri{e')  :  ai 


(*  =  1,2) 


F  F  K  =  k'  kind  F[a  :  fc]  F  e  =  e'  :  o’  F[q'  :  k]  F  e  o’ 
F  F  Aa:K,e  =  AaiK^e'  :  'ia\K.(T 


(a  0  Dom(F)) 


F  F  6  =  e'  :  WaiK.a  F  F  c  =  c'  :  k 
F  F  e[c]  =  e'[c']  :  o’[c/Qf] 


F  F  O’  =  flr'  type  F[a;  f  o’]  F  e  =  6'  :  o’  F[a;  \  <7\\-  e  cr 
F  F  fix{x:cr.e)  =  fix{x:a\e^)  :  o’ 


(^r^Dom(F)) 


F  F  6  =  e'  :  O’'  F  F  o’  =  o’'  type 
F  F  6  =  6'  :  O’ 
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r  f-  e  4- 1 

r  h  e  =  ★  :  1 


r  h  ei  4,  ^Ti  r[a;  :  <ti]  I-  62  :  (T2 

r  h  {Xx:(Ti,e2)ei  =  e2[ei/a;]  :  a2 


{x  0  Dom(r)) 


T  e  i  ai  (T2 
r  h  (Xxio'i  ,e  x)  =  e  :  <7i  (72 


{x  not  free  in  e) 


r  h  e  4-  ^  (72 

r  h  (A^:(7i.ex)  =  e  :  (Ti 


—  (a:  not  free  in  e) 
<72 


r }-  ei  4^  (Ti  r  h  62  4”  <^2 

r  I-  TTi  ((61,62))  =  ei  :  (Ti 


(i-1,2) 


r  h  6  :  (7i  X  (72 

r  h  (7ri(e),  7r2(6))  =  6  :  (Ji  x  (72 


r  h  c  :  fc  r[Q'  \  n\\-  e  :  a 
r  h  (Aq':k.6)[c]  =  e[c/a]  :  (7[c/ct'] 


^  Dom(r)) 


r  h  6  4^  Va:K.(7 
r  h  (Aa:/c.e[a])  =  6  :  Va:K.(7 


(cv  not  free  in  e) 


r  f-  (7  type  r[a:  ^  a]  e  X 
r  h  fix{x:cr.e)  =  e[^a:(a;:<7.e)/a;]  :  o’ 


{x  0  Dom(r)) 


A. 2  Structure  Calculus 


r  h  C  :  K 


r  h  6  ;  (7 


r  h  6  4^  (7 


r  h  5  $ig 


r  h  Si  =  S2  sig 


r  h  Fst{s)  :  K 


r  h  :  AC 


(5  :  [(a':K.(7]  €  P) 
(5  t  [a:n.o]  G  F) 


r  h  «nd(s)  :  <7[f^f(s)/a]  €  T) 

(. t [«--] € r) 


r  h  snd{s)  4.  o\_Fst{s)la] 


(5  :  [a’.K.o]  6  F) 


F  h  AC  kind  F[a  :  acI  h  (7  type  ,  ,  ,, 

- r  1  - —  a  0  Dorn  r 

F  h  [a:AC.(7]  525^ 

F  h  S  sig 
F  h  S  =  S  sig 
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r  h  52  =  5i  sig 
r  h  5i  =52  sig 

r  h  5i  =  52  sig  r  h  52  =  53  sig 
r  h  5i  =53  sig 

r  h  K  =  Ac'  kind  r[a  :  k]  h  <t  =  cr'  type 
T  h  [aiK.cr]  =  sig 


r  h  5i  <52  sig 

r  h  5i  =52  sig 
r  h  5i  <52  sig 

r  h  5i  <  52  sig  r  I-  52  <  53  sig 
r  h  5i  <53  sig 


T\-  M  :S 


r  h  K  <  k'  kind  r[a  :  k]\-  a  —  cr'  type  r[a  :  k']  h  a'  type 
r  h  [a:K.cr]  <  sig 


(a  i  Dom(r)) 


r  h  c  :  K  The:  cr[c/a]  r[a  :  k]  h  cr  type 
r  h  [c,  e]  :  [»:«:. (t] 


(a  0  Dom(r)) 


r\-  M iS 


r\-  M:  S'  T\-  S  <  S'  sig 
rhM:5 


ri-c:«  rhe4^  <7’[c/q']  r[a  :  k]  h  <7  i?/pe 
r  1-  [c,e]  4^  [a:K.<T] 


(a  0  Dom(r)) 


r  h  M  ;  5'  r  h  5  <  5' 

rn  M^5 


r  h  Ml  =  M2  :  5 

ri-M:5 
rhM  =  M:5 

r  h  M2  =  Ml  :  5 
r  h  Ml  =  Ms  :  5 


r  h  Ml  =  Ms  :  5  r  I-  Ms  =  Ms  :  5 
r  h  Ml  =  Ms  :  5 


r  \-  c  =  c'  :  K,  T  \-  e  =  e'  :  o-[c/a]  r[a  :  k]\-  (t  type 
r  h  [c,  e]  =  [c',e']  :  [a:K.<T] 


{a  i  Doin(r)) 


r  h  Ml  =  M2  :  5'  r  h  5  <  5'  sig 
r  1-  Ml  =  Ms  :  5 
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A*3  Recursive  Module  Calculus 


r\-  M  :S 


r[s^S]\-MiS  r  h  5  sig 
r  h  fix{s:SJ\d)  Ts 


(s  0  Dom(r)) 


r  h  Ml  =  M2  :  5 


r  h  «  kind  r[a  :  k]  h  cr  type  r[a  :  k]  h  c  :  k  r[a  :  /c][a;  ^  a]\-  e  i  a 
r  h  ^a:(s:[a:K.(7].[c[F5i(5)/a],e[F5f(s)5  snd(5)/a,  a;]])  =  [a  =  ^a:K:.c,/ia:(a::(T.e)]  :  [a:K.or] 


(a,  a:  0  Doin(r)) 


r  h  5  52^ 


ri-S..>  r[.:^hke(c:. ^  ,[<,/Frt(,)]J) 

r  h  ps.[a:Q(c  :  k),  (t]  525' 


r  h  5i  =52  sig 


r  f-  AC  kind  r[a  :  ac]  h  cr[a/F5f(s)]  type  T[/3  :  ac]  I-  5(c  :  ac)  A;mc? 
P5.[q?:Q(c[F5^(s)//3]  :  K),^r]  =  [a:Q{(p0:Kx)  :  k) ,  (T[a j Fst{s)^ 


(a  ^  Dom(r)) 
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